Optical Transport Networks such as those specified in the ITU-T G.709 recommendation are known, having a control plane to control nodes of such networks to reserve (set up) new paths by sending messages between the nodes to reserve resources at each node.
Classical RSVP (Resourse reSerVation Protocol) [RFC2205] signaling protocol is a known protocol for messages sent between nodes to set up new paths. RSVP-TE (RSVP-Traffic Engineering) [RFC3209] extends RSVP in order to provide a way to establish Label Switched Paths (LSPs) in MPLS (Multi-Protocol Label Switching). To reserve a path, an RSVP-TE (Traffic Engineering) PATH message, in the form of a Generalized Label Request, is sent out from the first node (which acts as an ingress node) via intermediate nodes along the proposed path, to the last node (acting as an egress node). The egress node returns an RSVP-TE RESV message to the ingress node, back along the path to cause the nodes along the path to confirm the reservation of resources such as bandwidth on switch paths and ports, for the requested path, for traffic of a signal type specified in the message.
It is non reliable in the sense that it relies on other mechanisms if a message is lost. It can recover from message lost via RSVP refresh messages. For example, if the sole tear message transmitted is lost, then resources will only be deallocated once the “cleanup timer” interval has passed.
RSVP-TE does not change the intrinsic RSVP unreliability described above.
GMPLS (Generalized MPLS) [RFC3945] generalized the concept of LSP. An LSP became regarded as meaning “any possible form of connection which someone is willing to control”. Again, GMPLS does not change the intrinsic RSVP unreliability aspect.
The message identification and acknowledgment mechanism defined in [RFC2961] addresses this problem. It provides a retransmission mechanism which can be applied to any RSVP signaling message (i.e. can be used in any context: RSVP, RSVP-TE).
[RFC2961] describes a number of RSVP-TE extensions for the support of reliable message delivery on a per hop basis. Standard RSVP, as defined in [RFC2205] keeps its state alive via the generation of refresh messages. Refresh messages are used to both synchronize node states between RSVP-TE neighbors and to recover from the loss of RSVP-TE messages. The use of refresh messages is relied on to recover from many different possible failure scenarios. This can be unsatisfactory.